home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-03-17 | 4.5 KB | 96 lines | [TEXT/ttxt] |
- MacBinary II+ Preliminary Specification
-
- This is a priliminary specification of an extension to the MacBinary II
- Standard to allow MacBinary to incorporate a directory tree in a similar
- way to a unix tar file. This is done by a fairly simple extension to
- the standard (which is documented seperately, and which you should be
- familiar with before reading this), basically, I defined a 128 byte
- block that marks the start of a folder, and another one that marks the
- end of the folder, and then set it up like this:
-
- start block for folder "Folder1"
- file1 - standard macbinary format
- file2
- start block for "Folder2"
- file3
- end block
- end block
-
- While the end block doesn't actually need to contain any information, its
- format is similar to the header block for consistency.
-
- Start Block:
- Offset 000-version 1 - this is incomptible with previous decoders.
- Offset 001-Byte, Length of foldername (must be in the range 1-63)
- Offset 002-1 to 63 chars, foldername (only "length" bytes are significant,
- the rest should be zero).
- Offset 065-Long Word, file type - 'fold'
- Offset 069-Long Word, file creator - $FFFFFFFF
- Offset 073-Byte, original Finder flags of folder (high byte)
- Offset 074-Byte, zero fill, must be zero for compatibility
- Offset 075-Word, folder's vertical position within its window.
- Offset 077-Word, folder's horizontal position within its window.
- Offset 079-Word, folder's window or folder ID.
- Offset 081-Byte, "Protected" flag (in low order bit).
- Offset 082-Byte, zero fill, must be zero for compatibility
- Offset 083-Long Word, Data Fork length 0
- Offset 087-Long Word, Resource Fork length 0
- Offset 091-Long Word, Folder's creation date
- Offset 095-Long Word, Folder's "last modified" date.
- Offset 099-Word, length of Get Info comment to be sent after the resource
- fork (if implemented, see below).
- *Offset 101-Byte, Finder Flags, bits 0-7. (Bits 8-15 are already in byte 73)
- *Offset 116-Long Word, Length of total files when packed files are unpacked.
- This may be zero to avoid having to preparse the folder when
- creating the MacBinary file.
- *Offset 120-Word, Length of a secondary header. If this is non-zero,
- Skip this many bytes (rounded up to the next multiple of 128)
- This is for future expansion only, when sending files with
- MacBinary, this word should be zero.
- *Offset 122-Byte, Version number of Macbinary II - 130
- *Offset 123-Byte, Minimum MacBinary II version needed to read this file - 130
- *Offset 124-Word, CRC of previous 124 bytes
-
- NOTE: The secondary header length MAY be non-zero, and if so, the secondary
- header immediately follows the Start Block, padded to a multiple of 128 bytes
- as usual.
-
- NOTE: The comment length MAY be non-zero, and if so, the comment immediately
- follows the Start Block or secondary header, padded to a multiple of 128
- bytes as usual.
-
- End Block:
- Offset 000-version 1 - this is incomptible with previous decoders.
- Offset 065-Long Word, file type - 'fold'
- Offset 069-Long Word, file creator - $FFFFFFFE
- *Offset 116-Long Word, Length of total files when packed files are unpacked.
- This may be zero.
- *Offset 120-Word, Length of a secondary header. If this is non-zero,
- Skip this many bytes (rounded up to the next multiple of 128)
- This is for future expansion only, when sending files with
- MacBinary, this word should be zero.
- *Offset 122-Byte, Version number of Macbinary II - 130
- *Offset 123-Byte, Minimum MacBinary II version needed to read this file - 130
- *Offset 124-Word, CRC of previous 124 bytes
-
- NOTE: This block is static except for the total length field, which may be
- zero as well, in which case its totally static.
-
- You should recognize the Start and End blocks by the version, file type and
- creator fields. Decoders MUST NOT rely on ANY other fields in the End Block
- being valid. Encoders MAY fill them out to look like a start block, or may
- zero-fill them. Encoders SHOULD zero-fill any bytes not explicitly set -
- this applies to all header blocks and all padding.
-
- All internal files should have version 0, MacBinary II version 129,129.
-
- An extended MacBinary file MUST start with a Start Block. Thus a
- MacBinary II+ file is either:
- 1) A MacBinary II file encoding a single file, OR
- 2) A MacBinary II+ file encoding a single folder.
-
- IMPORTANT: This proposed extentsion is not supported by anyone else, it probably never will be.
-
- If you have any comments, let me know.
- Peter <peter@cujo.curtin.edu.au>
-